IBIS Macromodel Task Group Meeting date: 28 July 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to report to the Open Forum that ATM recommends BIRD 178 be approved in in the next meeting, and that it be included in IBIS 6.1. - Done. - Mike L. to email the Open Forum to schedule the vote for BIRD 178 at the July 31, 2015 meeting. - Done. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Curtis: I received no feedback via email for last week's minutes. - Michael M: Motion to approve the minutes. - Mike L: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: - Arpad: We currently have only one active topic: - 7: "How to handle missing min/max data?" - I have no updates on that topic. - Arpad: Does anyone want to motion to untable any of the other topics? - Michael M: Could we get a status update on each of the tabled topics? - Arpad: We can go through the list. Item 8: Enforcing LTI-ness of analog models for AMI simulations. - Arpad: I haven't heard from Scott in several weeks now. - I'm not sure of his intentions for this. Item 9: Discuss language corrections regarding "ground". - Arpad: We decided to table this until IBIS 6.1 is finished and approved. Item 10: Back Channel and Optimization proposal (SiSoft). - Arpad: This is waiting for feedback from Cadence. - Ambrish communicated that he was unable to attend today and hadn't yet made any progress on gathering the feedback. Item 11: BIRD 147.1 and co-optimization (Cadence). - Arpad: I separated this from item 10 because we have an official BIRD 147 from Cadence and Walter had given an independent proposal. Item 12: New Redriver flow BIRD. - Walter: I have no new progress to report. - I'm not sure if we need that BIRD and will await Fangyi and others. - I found a clear error in the flow in the spec under certain circumstances. - I came up with a new flow. - Do we need it as a BIRD? I don't know. - Arpad: If there's a new flow, shouldn't the spec say something about it? - Walter: Not if we just consider it a reference flow. - Arpad: I'm concerned about that if all EDA vendors can do whatever they wish. - Walter: The people writing these models make them based on the flow I defined in the BIRD. Model makers are doing it that way. - Arpad: There's a flow in the spec and a flow in the BIRD. - The flow in the BIRD needs to be approved or rejected. - Walter: The BIRD is there now. - If it gets approved, that's fine. - I don't want to put more effort into pursuing that approval. - Radek: The BIRD doesn't solve all the issues, particularly if you have a chain of repeaters. - The question is whether there should be some guidelines related to some of the specific cases, so people understand them and know how to write models, as Walter said. - Bob: We need to discuss this further. - If the flow in the spec is wrong, then we have a problem. - Walter: To answer Arpad's original question: - SiSoft is prepared to have those discussions, but I'm not going to actively pursue the BIRD's approval. - Someone else may want to pursue it with modifications like Radek suggested. - Arpad: I believe that when we left it Walter and Fangyi were supposed to have a discussion on what should be in the BIRD. - Walter: We did not have those final discussions. - We got involved in other important things. - This wasn't my highest priority. - SiSoft is happy, but if others want it in the spec that's fine. - Radek wants more in the BIRD, so I'll defer. - Arpad: I would like to bring it to a close. - What's the next step? - Should Radek and Fangyi come back with more suggestions? - Radek: Yes, we can try to look at it. People are busy. - The issue is likely that things get too complex in certain scenarios. - Arpad: To answer Michael's original question, this BIRD is indefinitely tabled until people free up. Item 13: C_comp improvements. - Randy: This is waiting until the interconnect proposal is finished. - Much of this depends on the language in the interconnect proposal. Item 14: BIRD 128. - Radek: I was against the idea of BIRD 128. - I've often said I would rather have a separate API rather than hacking the existing GetWave() functionality. - I would be happy to fold a separate API into BIRD 147 or SiSoft's proposal. - I don't see a future for BIRD 128. - Walter: I worked very hard to make the backchannel proposals I did compatible with BIRD 128. - BIRD 128 was what Cadence and SiSoft did when we started this years ago. - I'd be willing to accept your proposal to drop BIRD 128. - Then we could just move ahead with my proposal. - We already have an API for a new Init() and we can add one for GetWave(). - It would be easy to update my proposals with a new API for GetWave(). - We could adopt my proposal for replacing BIRD 147. It does everything Cadence wants and everything everyone else wants. - Arpad: Will you formalize a BIRD? - Walter: I made the presentation. - If this group wants to move forward, I'd be happy to write up a BIRD. - Giving up being compatible with BIRD 147 would simplify it. - Radek: I think the idea was that Ambrish was supposed to come back with some feedback, but we haven't seen it yet. - Walter: Ambrish said their IC people aren't pushing them. - Doesn't sound like that feedback is going to happen. - Arpad: It has been over six months now. - How long do people feel we should wait for the feedback? - I don't want this wait period to stall progress. Item 15: Info, Out, InOut BIRD. - Arpad: This is ancient. I think we've had two new revisions of the spec since this topic came up. - I will take the AR: to see if it's even valid anymore. Item 16: DLL error trapping and return codes. - Arpad: Greg's proposal is also ancient. - Michael M: Is this in part being addressed by the quality task group and some .dll checking they were discussing? - Radek: It was partially addressed by some other BIRDs. - Arpad: A similar topic was on the reflector a few months ago. - Mike L: Greg was talking about the generic finger pointing problem. - Michael M. was referring to efforts to come up with a tool that does a little bit of inspection. - It has come up in the Open forum recently, too. - Hard to see us making too much progress. - It would involve a fair amount of code development. - Michael M: Someone on this call [David] has developed a free probing utility. - .dlls aren't totally opaque. - Are certain functions present? - Are they at least minimally conforming to expectations? - Does the existence of this tool address Greg's problems? - Do we need to put that in the official parser? - Arpad: We have had discussions in the past about the parser checking the .dll. - Should I send an email to Greg? - Michael M: I motion that Arpad email Greg. - David: Second. - Arpad: Anyone opposed? [none] - Mike L: In one of the quality meetings we presented a list of checks that could be done. - We could schedule to look at that in one of the ATM meetings. - Arpad: I was thinking the opposite. Perhaps quality could take this? - Mike L: Quality usually consists of Bob and Lance and myself. - Even if we were to do this in the parser, or python, etc., it helps to start with a spec for what we want to do. - Arpad: When do you want me to schedule it in this group? - Mike L: Next week would work. - Arpad: I'll email Greg and we can decide depending on his response. Item 17: Macro models for power delivery. - Walter: I was saying you can represent the time dependence of a power supply with spectral density. - Therefore, handle power variations either statistically or that spectral content can generate a power waveform. - No one has gotten excited about it, so we can remove this from the list. - Arpad: Is this useable for AMI purposes? - Walter: It could be used for AMI purposes. Rail voltage has direct frequency content on amplitude noise of the generated signal. - Arpad: I ask because that time varying waveform would violate LTI. - Walter: For statistical processing you'd do things like adding sinusoidal jitter. - For example, if you knew there was a lot of energy around 50MHz, then you'd put in sinusoidal jitter at 50MHz. - Arpad: Could this statistical approach for describing power supplies be translated into modifying the impulse response itself? - Walter: You could just modify the input waveform passed into Tx GetWave() and document that it's now really an analog signal not a digital signal. - Arpad: Should this topic be left on the list? - Walter: Unless someone says they have a problem to solve, let's remove it. - Arpad: I will take this off the list. New PAM4 Parameters Question: - Arpad: There are two PAM4 parameters, thresholds and offsets, that are In, Out, or InOut. - So the model could return new values for these from GetWave(). - If the model can return those values, are they supposed to be used real-time as the EDA tool generates the eye? - Do we have rules on when the values can be changed or returned? - Does it make sense for the models to return those values instead of having them in the AMI file? - Walter: Yes. - In practice, after a certain number of ignore bits are processed, the timing offsets and thresholds settle out and those are the ones that you use. They might change from call to call. - The EDA tool can accumulate that information as it sees fit. - Arpad: So should the EDA tool process the eye using the values from one GetWave() call to the next? - Walter: EDA tools can do creative things and differentiate themselves. - IBIS should just describe a model and what it returns. - Arpad: So the answer to my question is, "yes, it makes sense for the model to return the values." - Arpad: Any other discussions for today's meeting? [none] - Thank you all for joining. AR: Arpad to investigate the current relevance of tabled item 15. AR: Arpad to email Greg Edlund to ask about his current thoughts on his DLL error trapping topic (item 16). ------------- Next meeting: 4 August 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives